home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9707 / 000022_owner-linux-arm…r.rutgers.edu _Thu Jul 3 10:19:20 1997.msg < prev    next >
Internet Message Format  |  1997-11-30  |  4KB

  1. Return-Path: <owner-linux-arm-outgoing@vger.rutgers.edu>
  2. Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id KAA23484 for <willy@odie.fluff.org>; Thu, 3 Jul 1997 10:19:19 +0100
  3. Received: from root@vger.rutgers.edu (port 16511 [128.6.190.2]) by nic.funet.fi with ESMTP id <15595-9954>; Thu, 3 Jul 1997 12:16:08 +0300
  4. Received: by vger.rutgers.edu id <1000811-30852>; Thu, 3 Jul 1997 05:12:26 -0400
  5. Received: from IDENT-NOT-QUERIED@fm3.facility.pipex.com (port 33232 [194.131.104.13]) by vger.rutgers.edu with SMTP id <1000851-30852>; Thu, 3 Jul 1997 05:12:07 -0400
  6. Received: from succexpr.demon.co.uk [158.152.208.192] 
  7.     by fm3.facility.pipex.com with smtp (Exim 1.59 #22)
  8.     id 0wjh3U-0000FD-00; Thu, 3 Jul 1997 09:15:56 +0100
  9. Date:     Thu, 03 Jul 1997 10:03:57 +0100 (BST)
  10. From: "Neil A. Carson" <neil@causality.com>
  11. Subject: Re: Re ELF
  12. To: Matthew Wilcox <willy@odie.barnet.ac.uk>
  13. Cc: linux-arm@vger.rutgers.edu
  14. In-Reply-To: <199707030812.JAA22989@odie.barnet.ac.uk>
  15. Message-ID: <Marcel-1.09-0703090357-b49f3nA@succexpr.demon.co.uk>
  16. MIME-Version: 1.0
  17. Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
  18. X-Organization: Causality Limited
  19. X-Mailer: ANT RISCOS Marcel [ver
  20. Sender: owner-linux-arm@vger.rutgers.edu
  21. Precedence: bulk
  22. Status: RO
  23.  
  24. On Thu 03 Jul, Matthew Wilcox wrote:
  25. > > No, only if you're silly. If you're clever, you only do 16Kb.
  26. > I misremembered DECs recommendation then.  Sorry.
  27.  
  28. This is the noddy way of doing things. For example Digital's own code in their
  29. NC only uses 16kb :-) Maybe they've forgotten!!
  30.  
  31. > > I diasgree. Not many CPUs need to do this and considerably worse, I can't
  32. > > think of any mainstream ones to hand...
  33. > Other CPUs have to /effectively/ do this (ie flush the caches on a context
  34. > switch).  It's just that on the ARM, you have to do this yourself.  I was
  35. > basing the 'considerably worse' on the fact that other CPUs have large L1
  36. > caches.
  37.  
  38. No, they don't. Other processors cache by physical address, not by virtual
  39. address. So when memory is remapped they do not need to reflush. Some can
  40. also have memory-coherent caches, so even if you DMA in you still don't
  41. need to do a cache flush even if multiple CPUs are present (see the BeBox
  42. for example). The ARM caches by virtual address; this allows the MMU to run
  43. slower (and thus use less power) and also removes some extra logic.
  44.  
  45. > Cos 64MB * 48 = 3GB.  I was assuming the top GB would be reserved for
  46.  
  47. But so what? Why should you have to have a fixed size for every process?
  48.  
  49. > various bits of iffiness like kernel workspace and mapping devices into
  50. > and so on.  I suppose you could always do the Minix Thang and get each
  51. > binary to declare how much space it required and get more tasks in that
  52. > way, but then you end up with fragmented address spaces and all sorts of
  53. > horrible things.  Or you could maybe trade off a little - 96 tasks each
  54.  
  55. No. I agree with you it's nice a nice idea - but why would you have to do
  56. this? Allocate 1meg for each descending stack. You now how big a processes
  57. text area is so you only allocate it that for code. Data are is initially
  58. of a known size, and you could redirect calls to memory allocation to use
  59. somewhere else in the memory map.
  60.  
  61.     Neil
  62.  
  63. -- 
  64. Neil A. Carson
  65. Marketing Director              Causality Limited (London, UK)
  66. Tel/Fax: +44 (0)181 930 7408    Mobile: +44 (0)370 593183
  67. Email: neil@causality.com       WWW: http://www.causality.com.